- Get the latest version at: Wrye Morrowind
- For discussion, go to Elder Scrolls Forums
- Note: This document is incomplete, containing both incomplete text and references to items that I have not released yet!
- However, it stil contains a lot of useful information, and it will likely be a month or longer before I get a chance to complete it, so I'm releasing it as is.
- See Also
- General
- Cells
- Trading
- Journal
- Erroneous Else Firing [12/8/2004]
- Dialog
- Journal
- + More
- License
- Contact
- ...
- This is a collection of notes, warning and advice for both beginning and advanced Morrowind modders. It is not intended as an introduction to Morrowind modding or scripting, but it should be helpful to both beginning and advanced modders.
- Note that some of the advice is "how to do this", while other advice is along the lines of "this is the way that I think it should be done" – naturally you may disagree with this. Obvious examples of opinionated advice are the id and naming schemes. (And that's about as much apology as you're going to see for my opinions!)
+ A "+" bullet means that the following note or section is incomplete. It's really just a reminder to myself to work on this later.
? A "?" bullet (or in the text) indicates that a question, or something that I'm not sure of.
- [IMHO: ...] Indicates how I would like Bethesda to fix what I think is a design flaw. Obviously, it does not indicate how the game actually functions.
- [nickname] the first person whom I learned the info from (if I remember).
- This is not the same thing as a quote. Just means that I got a significant piece of the answer from them – which I may have then added to or mangled.
- Updated entries have a date postpended to them.
- Modding Introductions and Tutorials
+ Ghan Buri Ghan's "Morrowind Scripting for Dummies"
- Additional Modding Information
+ Item Catalog
+ Clothing Catalog
- ESMs
- Can add and modify object, dialog, faction, etc. data
- Can add references to existing cells.
- Cannot delete or modify references created by other ESMs.
? Attempting to delete will have no result.
? Attempting to modify a reference will result in duplicate references.
- ESPs
- Can add and modify object, dialog, faction, etc. data
- Can add references to existing cells.
- Can delete and modify references created by ESMs.
? However, if the player has already visited the cell in which those references reside, deletions and modifications will have no effect. [Result in duplicates references?]
- Cannot delete or modify references created by other ESPs
? Attempting to delete will have no result.
? Attempting to modify a reference will result in duplicate references.
- Loading: ESMs are loaded in chronological order, then ESPs are loaded in chronological order.
- The last mod in wins. If mods, A, B, and C modify the same database entry, and if mod C loads last, then any changes made by mods A and B are lost. However, if the data in question is remembered by the save game, then the save game data trumps mod C.
+ MyTools
- This is the set of tools that I use and what I use it for... Not necessarily the best current selection, but it works for me.
- Be careful of removing objects, factions, NPCs that dialog tests depend on.
- Finding global tests.
+ Cleaning
? Dependence on Other Mods
- Depends on whether you have a dial-up connection or not!
+ Docs files in Data Files/Docs/ModNameVersion.txt, etc.
- The standards promoted here follow Bethesda's predominant usage (except when noted otherwise). Note that I say "predominant"!
- Bethesda itself occasionally breaks these standards. (For the most part, these inconsistencies seem to be accidental rather than intentional on Bethesda's part.)
- Names for both cells and objects should be in title case.
- E.g., not "Balmora, east guard tower", but "Balmora, East Guard Tower"
- E.g., not "common shoes", but "Common Shoes"
- The one exception to this rule is for notes with descriptive names.
- E.g., "Scrawled note", "Note found on a corpse".
- House mods should not be named "vacant X" or "empty X" (after all, once you've moved in, it's not empty anymore!) Instead give the residence a proper name, e.g. "Aran House", "Karvesh Manor".
- For interior cells that are supposed to be within another area (typically a town), use the format "Area, subcell". E.g., "Balmora, Guild of Mages".)
- Interior mods with subcells (e.g., a huge house mod with several wings, a basement and an attic), you have two options:
- Pick one cell as the main cell and give it the base name (e.g., "Alpha House"), and give all other submods subnames (e.g., "Alpha House, East Wing"). If you go this route, then the main cell act as the main entry to the set of cells.
- Or else... Treat the main entry cell the same as the others (e.g., "Alpha House, Great Hall"). If you do this, then you may want to create an unreachable cell with the base name ("e.g., "Alpha House") solely for the purpose of facilitating dialog and script location testing. (E.g., Bloodmoon's "Solstheim" interior cell.)
+ Particular Buildings
? Telvanni towers
? Guild Buildings
+ Bethesda's standard for naming clothing is: "[Common|Expensive|Extravagant|Exquisite] [Shirt|Shoes|
+ Gloves, Pauldrons and Gauntlets should end with "Left/Right Glove/Pauldron/Gauntlet" I.e., do NOT begin the name with "Left/Right". (E.g., not "Left Glass Pauldron", but "Glass Left Pauldron")
- Motivation: This puts like items closer together in inventory view. (Ideally, Left/Right would be after glove, pauldron, etc. but that's contrary to Bethesda's standard.)
- When devising the name for a new armor type, try naming the right pauldron object first. If that name is too long to be allowed, then revise the name of your armor type. E.g., in my armor patch, I revise "Netch Leather" to "Netch" to avoid name length problems.
- See Wrye Patches C and documentation with it.
+ In brief:
? ???
- Don't use double spaces in topic text.
- When the entry is wrapped into the dialog display box, and the spaces fall at the end of a wrapped line, only the first space is discarded. The second space is wrapped to the beginning of the next displayed line, resulting in misalignment of text.
- Use square brackets for non-spoken parts of dialog.
- E.g., "[Hesitates] Yes, I do know Sul Matul. Why do you ask?"
- Don't use double dash for hyphen. It just doesn't look that good. Ideally, the game would al
? Can you paste a en or em dash into the editor?
- Use a blank line between paragraphs.
- Choice Responses
- Note that after a choice is made, the choice list disappears from the dialog box. (Also, the choice list never appears in in-game topic review.) Thus in writing the text entry, you should make sure that the text flows clearly even when the choice-list is not visible. For info dumps (see above) this isn't a problem, but for cases in which the player chooses from several options you might want to repeat the user's answer somehow.
- E.g., "So, you won't join me in my quest to rule the world??? Very well, then, Jimus Bondus, I have no choice but to send you to the Room of Doom!"
- You can change the name of an exterior cell simply by clicking on its name in the cell view and editing it. You may want to do this for reasons of dialog location testing and map marking.
- The last mod to load that modifies an exterior cell determines that cell's name – even if that last mod has no special name for the cell. I.e., if another mod that loads after your makes some trivial mod to your named exterior cell, it will still wipe out your new cell name, thus frustrating your dialog and cell marking intentions.
- Solutions:
- Be sure to load last! (Of course this is hard to guarantee without cheating – i.e., setting your mods date in the far future.) But this is pretty much the only way to win the name game.
- Don't rely on the cell being named correctly. Use something other than location testing, don't put any people outside, etc.
- Note: If you have several cells like "Alpha, Beta", "Alpha, Delta", "Alpha, Gamma", and you don't need an "Alpha" cell other than for dialog location testing, then you can make a dummy internal cell named "Alpha" instead of naming the exterior landscape. You need to dummy cell in order to get an "Alpha" to select in the location testing selector (or to have your location testing script successfully compile), but you don't have to make it reachable, nor does it have to have a door link to the Alpha "subcells".
- Each cell has a single landscape entry. If more than one mod changes the landscape for that cell, then the last mod to load will determine the landscape.
- To avoid conflicts with other mods, don't change the landscape in existing terrained cell – especially well-visited cells (cites and other popular modding sites).
- If you're adding a structure and feel the need to level or raise some land, try adding rocks and/or wooden walkways instead.
? Like landscape, each cell has a single pathgrid. Last mod to define the pathgrid wins.
- Wandering NPCs tend to stop on pathnodes. Hence, do not put pathnodes in doorways! The damn NPCs will wander into the doorway and then camp there, blocking your way. (Justifiable homicide in my opinion.)
+ Problems with allowing NPCs to wander while indoors.
- When you hover the cursor or pointer over an object, you see information about the object. Information displayed depends on the type and setting of the object.
- If you set an item's value or its weight to zero then the its value won't display on hover. [IMHO: Price should still display!]
- If you set an item's weight to zero then, its weight won't be displayed on hover.
- If you set an item's weight as less than 0.1 (but greater than 0), then it's weight will be rounded up to "0.1" on mouseover.
- Traders who buy/sell misc. items won't buy or sell keys, even though keys are misc. items. (I'm not sure how the game engine knows that the item is a key; my guess is that the engine keeps a list of all items that are used as unlockers for containers and doors.)
- Even if you set the value of an item to zero, a trader will still buy it for 1 gold (so long as he handles that type of item).
- Topics should arise naturally in conversation.
- Topics are ordinarily introduced in conversation – such introduction should not be awkward.
- Topics should be proper names or uncommon phrases which are not subphrases of existing topics or common words.
- The point here is to prevent accidental hyperlinking.
- E.g., the topic Shal seems to be okay since it's a proper name, but it's a subphrase of the common word "shall" – and as a result all uses of "shall" in the journal are hyperlinked to Shal.
- Topics should not be superphrases of existing topics.
- The point here is prevent topic shadowing.
- E.g., If there's a topic work, then don't create a topic called some work (as Bethesda mistakenly does in Tribunal).
- The problem here is that if a speaker tries to introduce the topic work through the phrase some work, then not only will the the word work not be hyperlinked, but also, it won't be added to the known-topics list!
- Topics should not be too long.
- Preferably the topic should not wrap while being displayed in the topic list.
- Also, longer topics are typically harder to work into conversation.
- Topics should not include personal pronouns – unless the topic will not be transferred between NPCs or to the PC's journal.
- E.g., my trade is fine so long as it is only used to refer the speaker's trade. I.e., so long as the NPC_1 does not say something like "ask NPC_2 about my trade or "ask NPC_2 about his trade, and so long as the player does not have a journal entry like "I asked NPC_1 about his trade."
- Given this reasoning, if a topic will always only be focused on the speaking NPC, then it's probably desirable to use the pronoun "my". E.g., my health, my background.
- And if the topic is always focussed on the PC, then it's probably desirable to use the pronoun "your". E.g., your reputation. (However, bear in mind that "your xxx" may already be a commonly used phrase.)
- Quest topics should disappear when the quest is done – unless keeping the topic serves some point in characterizing your relationship with the NPC.
- This is contrary to the way Bethesda handles topics, but I think that the motivation is obvious – left over quest topics clutter up the in-game topic list.
- E.g., I would keep the topic "Nerevarine" even after the main quest is over because it's so germane to the Morrowind world and your character, but I would hide most other quest related topics.
- Of course, you can remove the topic for some characters, but keep it for others. E.g., at the end of the Nalvilie Saren quest, I would keep the topic for Hlaren Remoran and Nalvyna Sarinith, but hide it for everyone else.
- To "remove" a topic when the associated quest is completed, you must make all of the entries associated with that topic fail. Basically this means that all entries must include a test against the quest's state variable (usually the index of the relevant journal topic). E.g., "..." Journal quest_01 < 100
- Dialog in Morrowind serves various purposes...
- General info
- E.g., little advice, morrowind lore, services, someone in particular
- Class experts and Savants.
- Characterization
- Race entries (what race think of themselves and of other races)
- Faction entries (what faction members think of themselves and other factions)
- Topic Introduction
- Introduce a new topic to the player.
- Questing:
- Establish and advance quests, and note or react to their completion.
- Information to help in completion of quests (location of places and people).
- A topic is introduced to the player when an NPC who is ready to speak about that topic, mentions that topic to the player. (E.g., Greeting5: "Hello there, %PCName! Would you be interested in a pair of boots? ") However, there are several caveats here...
- If the introduction matches another phrase which is also a topic (e.g., "a pair of boots"), then the engine will try to match to that topic instead of the one you intended. As a result, the desired topic phrase will not be hyperlinked and the topic will not be added to the user's known topic list.
- If the player does not become ready to talk about the topic until after the script attached to the introducing entry is run, then the topic will not be added to the known topics list.
- E.g., suppose that the introducer script is "journal pairOfBoots 10", and the first entry requires that "journal pairOfBoots == 10".
- The reason for this is that the engine determines which topics to add to the known-topic list before it runs the script attached to an entry. Since the NPC is not ready to talk to about the topic at that time, the topic is not added to it.
- If you add a topic through the addtopic command in the script for entry, then the new topic will not show up until the player clicks on another conversational topic. This is for pretty much the same reason as above: this topic list is determined before the entry script is run.
- Introducer
- Introduces a quest or reminds the player of a quest.
- Introducers typically are given in the greeting or in a distributor topic.
- Introducers should either introduce the quest topic, or introduce a distributor topic.
- E.g., Have you seen my husband, Danar Uvelas? Or "Are you here on business? "
- Introducers typically do not advance or initiate the quest, and typically should not be remembered in the in-game topic review.
- Distributor
- An introducer for a series of quests. E.g. business, chores, duties, etc. topics.
- Advancer
- An entry that advances a quest. I.e., an entry that is required to move the text towards completion.
- Usually this is marked by a journal entry, but for some actions this may be overkill, especially if the advancement is marked by something else (e.g., receiving some item).
- Initiator
- An advancer that initiates a quest.
- Completer
- An advancer that completes a quest.
- Informer
- An entry that provides information to help complete a quest, but which is not essential to completion of the quest. Such an entry may or may not produce a journal entry.
- E.g. entries that tell you where to find Caius Cosades for the initial "find spymaster" quest.
- Reactor
- Anentry that reacts to the player's involvement in or completion of a quest.
- E.g., comments on Ienas Sarandas in Ald'ruhn, or breeding netches in Gnaar Mak after the player has completed those quests.
- E.g., comments on Nerevarine after player has acquired Nerevar's Moon and Star ring.
- Note: See Quest Entry Types above for terminology.
- Morrowind basically has two types of quest structures: one-offs (e.g., miscellaneous and town quests), and serial quests (faction quests). One-off quests are typically initiated in a greeting, while serial quests are typically introduced through a distributor topic (*business, chores, etc.).
- For serial quests, what form should the greeting reminder take?
- Reminding you of the current quest is more urgent, but also more work. It's simpler, and usually sufficient, to just remind the player of the distributor topic (e.g., "Have you been lax in your duties? ")
- For serial quests, why have a distributor topic? Why not just put the current quest introduction/reminder in the greeting?
- Making the greeting the distributor is more urgent – probably more urgent than is desirable for more serial quests. After all, you've got other things than quests to talk about with faction members.
- A mechanical reason is that there are a lot of greeting entries, but not so many topic entries. I.e., you're less likely to get lost in a sea of dialog entries if you're working in the distributor topic.
- Also, it's harder to stall the speaker. I.e., perhaps you want to talk with them about something else before deciding whether to address the quest with them.
- Why not use the greeting as advancer (initiator, completer)?
- Same reasons as above, plus...
- Greetings cannot appear in the in-game topic-review – and usually you want quest advancers to appear in the topic review.
- Uber Quests
- There are also uber-quests, such as Morrowind's main story line, but these have no formal existence in the game, rather they exist through the linkages between their component quests.
- Quest entries should be in chronological order.
- In in-game topic-review, topic entries appear in their database order. Ideally, the game engine would recall not just which dialog entries had been said, but what order they had been said in (as it does for the in-game quest review). So, lacking this ideal state, in-game topic-review will only be chronological if the dialog database is also chronologically ordered.
- The problem with this is that putting the database into chronological order is quite a bit of extra work, and in some cases may be practically impossible.
- Note: Non-topic dialog (greetings, persuasion, etc.) do not appear in the in-game topic review, so chronological ordering is not necessary.
- A brief explanation... The first entry under a topic to pass its condition tests shadows all following entries. I.e., for any following entry, there's an implicit test of "and none of the previous entries are true". Now, if you reverse the order of the entries, or if you want to make the topic go away, then you'll have to make at least some of those implicit tests explicit. I.e., you'll have define more test conditions for previously shadowed entries.
- Several aspects of dialog testing make reverse chronological order more natural than chronological order...
- Place Testing... Suppose that you're looking for someone in the Fishmonger's Hall in Vivec. Chronologically, you should put the general Vivec entry first, then the general St. Olm's entry, then the Fishmonger's Hall entry, and finally that person's entry. (After all, if you were in the Fishmonger's Hall and asked about that person, they'd say "they're over there" and you wouldn't then go out into greater Vivec and ask where that person was.) However, if you didn't care about chronological ordering, then you would put the person's entry first, then the general Fishmonger's Hall entry, then the general St. Olms entry, then the general Vivec entry. With chronological ordering you have to add additional tests (for Fishmongers: "not id == X"; for St. Olms: "not ID == X" and not cell == Fishmonger's", and for Vivec: "not ID == X" and "not cell == St. Olms").
- Choices... Because of the way the choice function is handled, you're generally required to put the choice test generator after the choices, which would be of course out of chronological order. The way out of this is to set some state variable which temporarily invalidates the choice generator (e.g., see Info Dump below).
- Disposition... Chronologically, higher disposition entries should come after lower disposition entries (you're talking or bribing your way into more favorable responses). But engine-wise, the higher disposition entries must come first (if lower disposition entries came first, then they would permanently the higher entries).
- Rank... Chronologically, rank testing entries should have lower ranks first and higher ranks later. But again, engine-wise, the higher rank entries must come first.
- Generally, the easiest way to create entries is to copy and existing entry and modify the new copy. This has two results: 1) entries with similar test conditions (id, cell, journal, etc.) are typically grouped together, and 2) entries appear in reverse creation order (because the copy entry appears above the original entry). The result is that the entries typically do not appear in chronological order.
- Fortunately, you can use the left and right arrow keys to move entries up and down in the list. Unfortunately, you can only do this while the entry list is not filtered by speaker (which it often is). Also, unfortunately, it's harder to review the tests for particular speakers after they've been moved into chronological order.
- For complex topics (especially those with tests on rank and/or disposition), perfect chronological order may be impossible or too difficult to be practical. Near chronological order is generally achievable, but often at the cost of substantial additional work.
- For a demo of chronological ordering, see Wrye Demo. In this demo, I convert Ajira's Mage's Guild quest topics and Larrius Varro's info dump (see below) to chronological order. 12/8/2004
- Background: An info dump is where several topic entries are linked together through ‘choice "Continue" N' statements in their attached scripts. Info dumps are necessary when you want to give the user more text then will fit into a single entry. (E.g., Larrius Varro's "little story".)
- The problem with info-dumps is that the chronologically first entry must go last. (If you put it first, ahead of the entries that test for "function choice == N", then those entries would never get executed.)
- There are a couple of ways to allow info dumps, but still keep chronological ordering:
- Use clearInfoActor on the entry that starts the info dump. You still have to put it last, but you don't care anymore because it doesn't appear in the in-game topic review. However, it makes the user click through an extra, typically useless entry, e.g. "I'm going to tell you my story now... Continue". This is annoying and doesn't read well – unless there's a real choice for the user. But if there's a real choice for the user, then the entry is probably interesting enough that you don't want to use clearInfoActor.
- Use an additional variable to prevent the first entry from refiring. This is what I typically do – in fact I use the generic state variable to index into my info dump. E.g.:
"Entry 0..." Conditions: [wr_genInfoDump == 0] Script: [choice "Continue" 1; set wr_genInfoDump to 1]
"Entry 1..." Conditions: [wr_genInfoDump == 1] Script: [choice "Continue" 1; set wr_genInfoDump to 2]
"Entry 2..." Conditions: [wr_genInfoDump == 2] Script: [set wr_genInfoDump to 0]
Notes:
- Be sure to set wr_genInfoDump back to 0 at the end.
- You don't have to test against function choice – instead, indexing is provided by wr_genInfoDump.
- Most likely, you'll add tests against journal number, etc. to avoid repeating the info dump.
- Note: See Wrye Demo for an example. 12/8/2004
- clearInfoActor prevents a topic entry appearing in the in-game topic review. Note that non-topic dialog entries (greetings, persuasion responses, etc.) don't need clearInfoActor because they never appear in in-game topic review.
- When to clearInfoActor
- On trivial dialog that the player doesn't need/want to review.
- On out-of-order topic entries. (See Chronological Order above.)
- On distributor topics like business, chores, etc. that don't actually advance the quest.
- On entries that use global variable substitution where that global variable may change. E.g., PCRace won't change (unless a plugin breaks this basic game assumption), but variables like gamehour, etc. will change.
- Be aware that "PC Talked" resets to 0 after a while. (As I understand it, it resets if the user has not encountered the NPC within the past 72 hours of game time.) Thus, don't assume that a PC Talked test will only run once!
- If you need to make sure that the dialog only runs once use some other variable to remember the encounter and test on it.
- In writing entries which test on cell location, be sure to consider the possibility that a companion may be brought into the cell. Generally, such responses should be nolored to prevent them from being incorrectly applied to your companion. (Assuming that all companions have nolore defined.) (A nolored entry is an entry that includes a condition "not local nolore == 0".)
- An example where this is broken is the greetings in Tel Fyr. The way these are defined, if you talk to your companion after killing one of your locals, they'll attack you!
- Although location testing is defined for the NPC, it actually tests the player's cell, not the NPC's cell. Of course, usually this is the same thing, but occasionally they're different.
- Remote speaker. You've used forceGreeting to talk to an NPC which is outside the player's current cell.
- Boundary line. Player activates an NPC that is standing across an exterior cell boundary line from the player. Obviously, the NPC has to either be standing very close to the boundary line and/or the player uses a telekinesis spell to talk to a relatively distant NPC.
? Exterior cell name has not kicked in yet. Named exterior cells do not click on and off exactly as you cross and re-cross a boundary, but rather seem a bit sticky. I.e., they wait until you've been outside or inside the cell area for a second or two before they kick in. So, it's possible to start a conversation with an NPC when the cell name change has not kicked in yet, and thus have the location test misfire.
- Th explanation in TES of notLocal is quite confusing, seeming to imply special numbers of 5, -3, etc. or that the variable "nolore" is treated specially. The reality is simpler, though still a little confusing...
- Not local tests will pass if: 1) the specified variable is not defined by the speakers script, or 2) if the condition described is not true. (I find that the easiest way to think about the second case is to reverse the condition described in the entry. E.g., if the condition is: "not local nolore == 0", then think of it as "local nolore != 0".)
- Almost all tests against nolore are stated as "not local nolore == 0". So, if you have nolore defined, the test will pass if you have nolore set to anything other than 0.
- Given this behavior, Bethesda could have defined levels of lore, e.g.:
loreLevel == 0 no lore
loreLevel == 1 faction lore
loreLevel == 2 faction, class lore
loreLevel == 3 faction, class, race lore
loreLevel == 4 faction, class, race, local lore
- Tests would then have been:
not local loreLevel < 1 [faction topics]
not local loreLevel < 2 [class topics]
not local loreLevel < 3 [race topics]
not local loreLevel < 4 [local topics]
- Such a leveled lore system would have been useful for companions and other travelers (who should not have local lore), but could also have been useful for other characters – e.g. the head of the guild who might be willing to talk about faction stuff, but not tell you where to find the local barbershop.
- I take "lore" to mean in effect, "common knowledge". NPCs should be nolored when their character is such that they're not likely to waste their time talking about common knowledge, or when talking about common knowledge could cause problems (e.g., companions who should not know local lore).
- Bethesda seems to have been a bit sloppy about using nolore – i.e., they don't use nolore as much as they should. I.e., you'll run into some clearly nolored characters who have a few generic topics. E.g., all members of House Hlaalu will have a "House Hlaalu" topic, even if they've been nolored.
- Rather than deleting an existing entry (from another module), hide it. I.e., set it so that it will always fail the dialog test. Hiding an entry is less likely to cause problems than deleting the entry.
- E.g., define a global variable wr_num1 and set it to 1. Then in the dialog, test for wr_num1 == 0.
+ Occasionally the player learns a quest topic before that quest has been introduced. E.g., both the Imperial Legion and the Thieves guild have scrap metal quests. As a result, if you ???
- They sometimes appear before they should. E.g., the "scrap metal" topic appear for Aengoth the Jeweler in Ald'ruhn before it has been introduced through the "jobs" quest introducer.
+ See Wrye Demo Mod.
+ Favored
- action
- prevDay, prevEquip, etc.
+ Deprecated
- doneOnce
- state
- Unlike in-game topic review, in-game journal review does not depend on the order of topic entries in the mod database! Instead, in-game topic review reflects the order in which the entries were actually placed into your in-game journal. This is because in-game journal is actually written into the game save file as it's created, but only the id number of visited topic entries (that don't have clearInfoActor) are remembered.
- Also surprisingly, journal entries do not have to be in order in the database! E.g., entry 100 can be placed before entry 50.
- Nonetheless, while modding, you'll most likely find it easiest to understand journal topics if their entries are placed in chronological (index) order.
- Surprisingly, different journal topics can be given the same quest name! When this is done, all of the quest entries from the journal topics with the same name are lumped together in the in-game quest view.
- This is useful when a given quest has sub quests and/or side quests that have no fixed chronological order (in relation to each other).
- Powerful as TES is, the scripting engine really looks hacked together at times. Below, my [IMHO: ...] (humble opinion) notes state my suggestions for next generation TESCS.
- Don't start object names with an underscore. Such names, when used in scripts cause run-time failures for certain operations. [IMHO: TESCS should reject names that start with an underscore. Or it should allow using them in script. Or it should at least give you a compile time warning.]
- When specifying a float value between -1 and 1, be sure to start with a zero. E.g., Not "-.2", but "-0.2". Otherwise, you'll get a runtime error. [IMHO: Compiler should handle these numbers correctly.]
- GBG advocates using commas between function variables. I never do, and I haven't seen a problem.
- Buri Gan advocates putting spaces between function variables, parentheses, etc. I do this between variables, but not usually between code and parentheses.
- NEVER put a space before the fix ‘->' operator. In my experience doing so always causes bizarre scripting crashes at some unpredictable time after the problematic script runs.
- If you have a "forceGreeting" in an if/elseif block, then the script will not jump to the endif statement, but instead continue with the next elseif or else statement (which means that if you have an "else" clause at the end, it WILL fire.
- Solution to this is to put a "return" at the end of the block that erroneously allows fall through.
- E.g.,
elseif ( iTest )
fooBar->forceGreeting
return
else
...
- Apparently, the engine doesn't save global script variables unless the global script has run at least once in the current load-session. [IMHO: Global script vars should be saved regardless.]
- So if your global script has variables that it needs to have remembered, either: 1) save those variables outside the script (e.g., in a global), or 2) make sure that the script runs at least once per session.
- If you go the second route, then you might do something like this:
- Create a keepAlive startup script (this will be started at the beginning of each load or new game.)
- Have keepAlive check to see if each of your persistent-memory requiring global scripts are running. For each such script (e.g., myScriptGS) that is not running, set some flag to note why the script is being started ("set myScriptGS.keepAlive to 1"), and then start that script. The target script should then check the keepAlive variable at the start, and if it's set to 1, set it back to zero, stop itself and return.
- You can set global script variables from outside, but you can't read them. This is opposed to object script variables which can be both set and (in certain conditions) read from outside.
- [IMHO: This should be allowed. At the very least it should generate compile time warnings.]
- The engine maintains a list of active scripts, which is essentially all local scripts + all running global scripts, and (usually) executes each of these scripts in turn once per frame.
- However, there seem to be times when the engine does not execute all of the active scripts for a given frame. I.e. it will run some scripts, but not all of them. So be careful when writing scripts that assume that they get run every frame.
- I don't know why this happens but it may be related to scripts starting or stopping. I.e., maybe halfway through the active script list, a script starts or stops a global script and as result, the global script executor resets until the next frame. Hence half the scripts get execute in that frame, but the other half do not.
? In what order do scripts get executed (alphabetical?, load order? start order?)
? Is the order the same from one frame to the next?
? Is it the same from one load or game session to another?
? Is it affected by the loading order of plugins?
- CellChanged gets send immediately after the player changes cells. Note that this means a local script running in an interior cell won't fire when the user leaves a cell, but rather when the player enters the cell. (Thus for the slave scripts, the slaves don't disable when you leave the cell, but rather the next time that you enter the cell.)
? I don't know what happens when a player moves between exterior cell boundaries. Does cellChanged fire every time the player crosses a cell boundary? Or is it less frequent than that (e.g., when a cell loads, or when the cell name changes?)
- Sometimes CellChanged fails to fire. I don't know why this is. (In my limited experience, it seems to happen more frequently for simple cells than complex cells. Maybe it's because some script is starting or stopping? Maybe it's because there are no NPCs in the cell?)
- My work around for this problem has been to first test on cellChanged, and then also test every 100 frames or so.
- StopScript doesn't actually stop a script – instead it removes the script from the list of scripts to be run. I.e., it keeps the script from running again. Which is pretty much the same thing unless the stopscript command is made from within the script itself. In that case, the script will continue to process in the normal way after the stopscript command until it ends (and then it won't run again).
- So if you want the script to stop processing after the stopscript statement, add a "return" or make sure that the script logic doesn't allow anything to happen after the stopscript statement.
- If you warp your character to a graphically complex area above a structure or element of terrain, you may find that your character has fallen into the structure and gotten stuck there. Apparently, your character gets warped and gets floored to the local terrain before the structure is actually added, so that when the structure is added, you get a collision problem. In less complex areas, this isn't a problem because all objects have time to get added before the player gets floored.
- Simplest solution is to warp the player to a location over terrain, not over structure.
- I've heard that using "fixme" on arrival will fix this problem, but I haven't tried this. 12/8/2004
- There often seem to be drawing problems when using position or positionCell to move NPCs and objects between cells.
- For NPCs, the NPC can end up in some sort of bizarre inside-out and/or in front of everything else state. And or the NPC can float in air, fail to carry out their AI, and fail to be activated by clicks. Horrific as these problems are, they seem to resolve themselves in the player simply leaves and re-enters the cell. (If you're outside, then you'll probably have to move at least three cells away before returning because of exterior cell loading rules.
- For objects, the problems can be worse and seem to be related to whether the player has previously encountered the object in the current load session. Effects are mispositioning (object appears in wrong place) and texture cycling (textures covering object cycle – actually looks kind of cool until you CTD after a second or so!) (Note: I've only tried this sort of positioning with a container that I designed to "follow" the player around to different locations.)
- Apparently these problems are solved by the use of "fixme". I haven't tried this for NPC's, but it works fine for objects. I use it in Wrye Luggage after pos'ing luggage to the cell (unless I know that the luggage object has already loaded in the current load session. [cdcooley] 12/8/2004
- "fixme" works because it actually reloads the entire cell.
- For NPCs and creatures, after placing, disable them in one frame and then re-enable them in the next frame. This will fix their drawing strangeness. I.e., it's not necessary to use fixme (which can take a little while). However, the scripting is a little more complicated than using fixme. [cdcooley] 12/8/2004
- For player (and NPC's?) position and positionCell measure is in degrees. For objects, it's something else – god knows what, but it seems to work out to about 57x the number of degrees. Which is not radians, gradients or any rotational measure that I know of.
- Note that placeItem uses degrees for objects, SFAIK. 12/8/2004
+ GetSecondsPassed
+ GameHour
+ Frame counting
+ New Day
+ 24 hours
+ New Load Session
- Things that I'd like to see Bethesda implement in Oblivion and later...
- In-game topic review should show entries in order in which player heard them rather than in database order.
- Skip-Topic entries should be supported. Skip-Topic entries would cause the the topic to not be displayed for the speaking NPC if it's the first passing entry for that topic. This would provide a simpler and more powerful mechanism for keeping NPCs from talking about topics than is currently available. Syntax: Dialog text is an empty string (or something like "SKIP").
- Index only dialog entries should be allowed. This would allow the journal index to be incremented without generating a visible dialog entry. (E.g., as a modder I need to advance the quest state variables, but the advance is not worth noting with a dialog entry to the player.)
? Namespaces
- Support for refactoring.
? Support for in-game dialog entry
- Character dialog groups
- Managing mods
- Uber items outside of normal economy
- In-game service activation/de-activation.
- Allow more than 4 travel destinations.
- Allow user to specify how stuff is sorted in inventory and spell windows.
- Feel free to mirror this.
- For discussion of Wrye mods, etc., visit Elder Scrolls forums. My id there is "Wrye".
- However, like most Morrowind modders, I already spend waaaaayyyy too much time modding. So, I may not be very responsive.